home *** CD-ROM | disk | FTP | other *** search
/ Gigarom 4 / Mac Giga-ROM 4.0 - 1993.toast / FILES / DEV / I-Z / TADS v2.0.sit / TADSVER.MAC < prev    next >
Text File  |  1992-12-20  |  8KB  |  174 lines
  1. This file contains a list of changes that have been made to TADS
  2. since the initial 2.0 release.  Most of the changes are fixes to
  3. bugs, so they don't change the documented behavior, but a few, as
  4. explained below, add new functionality to TADS.
  5.  
  6. 2.0.11  12/20/92  bug fixes
  7.  
  8.   - Goto statement labels were occasionally not released properly,
  9.     resulting in spurious internal errors.
  10.  
  11.   - The 'continue' statement did not work as documented in 'for'
  12.     statements.  Instead of jumping to the re-initializer expression,
  13.     as it now does, the 'continue' incorrectly jumped to the condition.
  14.  
  15.   - The run-time is now slightly smaller and faster.
  16.  
  17.   - The compiler generated spurious internal warning messages when
  18.     switch statements were used.  The warnings did not indicate any
  19.     actual problem, and have been removed.
  20.  
  21.   - The compiler did not process locals correctly when multiple disjoint
  22.     blocks within a function or method had locals, and a later block had
  23.     fewer locals than a previous block (yes, it's a somewhat obscure bug).
  24.  
  25. 2.0.10  12/14/92  minor changes
  26.  
  27.   - The startup dialogs now fit better on standard (Plus/SE) monitors.
  28.  
  29.   - Output is faster in the run-time.
  30.  
  31.   - The Debugger sometimes couldn't find include files that weren't
  32.     in the current directory (even when the source path had been properly
  33.     set up with the startup dialog); this has been fixed.
  34.  
  35. 2.0.9  12/12/92  New features
  36.  
  37.   - NEW FEATURE:  the new user function commandPrompt, if provided by
  38.     the user's game program, will be called prior to each player command.
  39.     If the commandPrompt function is provided, the default ">" prompt is
  40.     NOT displayed; if no commandPrompt function is defined, the default ">"
  41.     is used.  This should not affect existing games at all, unless a game
  42.     defines its own function, method, or property called commandPrompt
  43.     having a different purpose.  The commandPrompt function returns no
  44.     value.  The function takes a single argument:  a number, indicating
  45.     the type of command that the system is prompting for:
  46.  
  47.        0  - normal command
  48.        1  - command after invalid word (allowing "oops" to be used)
  49.        2  - disambiguation (after "which x do you mean..." question)
  50.        3  - command after askdo (after "what do you want to x?")
  51.        4  - command after askio
  52.  
  53.     Note that the default prompt in all cases is simply ">", and in all
  54.     cases a new command can be entered.  However, when the type code is
  55.     2, 3, or 4, a question has just been displayed by the run-time, so
  56.     the commandPrompt function may want to suppress any pre-command
  57.     information or prompt text.  Case 1 is generally identical to case 0.
  58.  
  59.   - NEW FEATURE:  A new built-in function has been added, which allows
  60.     the game program to suppress the display of text that would normally
  61.     be displayed with double-quoted strings or the say() function.  The
  62.     function is called outhide(), and it takes one argument:  a flag,
  63.     indicating whether to suppress or re-enable the display of output.
  64.     If the flag is true, output is suppressed; if the flag is nil, output
  65.     is re-enabled.  Any output that occurs between outhide(true) and
  66.     outhide(nil) is discarded.  However, outhide(nil) returns a value
  67.     indicating whether any output did in fact occur since the call to
  68.     outhide(true); this allows you to determine if any output would have
  69.     occurred, even though the output is not seen by the player.  Note
  70.     that this is effectively the same mechanism used by the player command
  71.     parser for noun disambiguation using the verDoXxx and verIoXxx
  72.     methods, as described in the TADS author's manual.  There is no way
  73.     to recover the text that was suppressed by outhide(); the text is
  74.     simply discarded, so the only information available is whether any
  75.     text was generated.
  76.  
  77. 2.0.8  12/03/92  Mac bug fixes and minor changes
  78.  
  79.   - The "disable argument checking" option in the v1 compatibility
  80.     dialog was reversed - checking the box would actually enable argument
  81.     checking, while leaving it unchecked would disable it.
  82.  
  83.   - The include path list was not applied correctly in certain cases.
  84.  
  85.   - The startup dialogs were too large for a standard (9 inch) monitor.
  86.  
  87.   - NEW FEATURE:  When the keyword $$ABEND is typed as the entire command,
  88.     the run-time immediately terminates and returns to DOS.  This emergency
  89.     escape is provided so that TR can be terminated if the game somehow
  90.     gets into a state where a more graceful exit is not possible.
  91.  
  92.   - NEW FEATURE:  The parser now calls two new optional methods in the
  93.     game program.  These new methods are intended to help speed up the
  94.     identification of words when many objects have the same vocabulary.
  95.     If the new methods are not present, behavior is the same as before,
  96.     so existing games will run unchanged.  The new methods are validDoList
  97.     and validIoList; they are associated with the "deepverb" object for
  98.     the current command.  They are called with three parameters:  the actor,
  99.     the prep, and the other object (indirect object for validDoList and
  100.     direct object for validIoList; the value of the parameter will be nil
  101.     if not applicable).  These methods are called prior to the disambiguation
  102.     pass (using verDoXxx/verIoXxx), and prior to testing any objects with
  103.     validDo/validIo.
  104.  
  105.     The return value of validDoList/validIoList is a list of all of the
  106.     valid objects for the verb.  It is fine for these methods to return
  107.     *too many* objects, since each object is still tested with validDo
  108.     (or validIo) and the appropriate verDoXxx/verIoXxx methods.  Generally,
  109.     these methods should simply return a list of all of the accessible
  110.     objects in the actor's current location (or the actor's location's
  111.     location), plus a list of all of the "floating" objects (which use
  112.     methods for the location properties).
  113.  
  114.     An appropriate definition for validDoList in the deepverb object
  115.     appears below:
  116.  
  117.        validDoList(actor, prep, iobj) =
  118.        {
  119.            local ret;
  120.           local loc;
  121.  
  122.        loc := actor.location;
  123.        while (loc.location) loc := loc.location;
  124.        ret := visibleList(actor) + visibleList(loc)
  125.               + global.floatingList;
  126.        return(ret);
  127.        }
  128.  
  129.     This same definition (with the name changed) is appropriate
  130.     for validIoList in deepverb.  This returns a list of all of the
  131.     objects visible in the current location, plus the global list of
  132.     all floating objects; this should be a superset of the list of
  133.     accessible objects in most games.  The only verbs that normally
  134.     requires a different value of validIoList/validDoList are verbs
  135.     such as "ask" and "tell" that allow any object (whether accessible
  136.     or not) to be used as indirect objects; for these, simply use this
  137.     definition:
  138.  
  139.        validIoList = nil
  140.  
  141.     This takes advantage of the reverse compatibility feature:  when the
  142.     method returns nil, all objects with matching vocabulary are used.
  143.  
  144.     The one additional game change required to take advantage of this
  145.     new feature is that global.floatingList must be built during
  146.     initialization.  This can be done easily with the following loop:
  147.  
  148.        global.floatingList := [];
  149.        for (o := firstobj(floatingItem) ; o ; o := nextobj(o, floatingItem))
  150.           global.floatingList += o;
  151.  
  152.     This should be placed in the preinit or init function.  Note that
  153.     all objects which have location methods should be declared to be
  154.     of class floatingItem:
  155.  
  156.       class floatingItem: object;
  157.  
  158.     This class doesn't do anything except serve as a flag that an
  159.     object should be placed in the floatingList.
  160.  
  161. 2.0.7  12/01/92  Macintosh bug fix release
  162.  
  163.   - The run-time occasionally missed the \ in an escape sequence in
  164.     output strings.
  165.  
  166.   - The software would not run on 68000-based (Plus and SE) Macs due to
  167.     an alignment error.
  168.  
  169.   - If a "save" command was executed prior to a "restore", the .GAM
  170.     file would be overwritten with the saved game data.
  171.  
  172. 2.0.6  11/24/92  first general Macintosh TADS 2.0 release
  173.  
  174.